Hi!

Please @KevScarr, @rartych take a look to the proposal next week. If we agree on this I will merge during next week

Offtopic: Next week I am delivering API PRs (code and test definitions) for aligment with Transversal WG Public releases

@PedroDiez Since we have a lot of discussions about misuse of device identification error responses, I think the same privacy conserns may be raised for phoneNumber and idDocument , so I used AI tools to invastigate on it, here is the short summary:

When designing API error responses for parameters like phoneNumber and idDocument, it's crucial to implement security-focused error handling that prevents information disclosure and user enumeration attacks.

Core Security Principles

The fundamental principle is to avoid revealing which specific parameter caused the validation failure. Error messages should never distinguish between different types of validation failures that could help attackers determine valid vs. invalid data combinations.

Recommended Error Response Strategy

Use Generic, Uniform Error Messages
For all parameter validation failures, return the same generic error message - see Authentication and Error Messages section in OWASP Cheat Sheet

Taking into account "Privacy by Design" paradigm the CUSTOMER_INSIGHTS.IDENTIFIERS_MISMATCH error looks better.
Or to distinguish it from Device identifcation error it can be named like: CUSTOMER_INSIGHTS.INVALID_IDENTIFIERS
The message should be more generic than: Provided idDocument is not consistent with the phone number.
Maybe this:

            GENERIC_422_INVALID_IDENTIFIERS:
              description: The request contains invalid data identifying customer
              value:
                status: 422
                code: CUSTOMER_INSIGHTS.INVALID_IDENTIFIERS
                message: The request contains invalid data.

When phoneNumber is in the token, then it is still obvious that idDocument is wrong, but we may have other identifiers in the future.
Maybe we can review the errors in the next release.

BTW.
I guess this issue should be covered in Commonalities API Design Guide - Security section.

Hi,

@rartych I agree with the comment and i think that it is a point for MetaRelease Spring 26 enhancement, not pnly to apply in Customer Insights but also in other APIs when happening that scenario. I will be opening an issue in Commonalities next week.
cc @KevScarr

Then, in the context of this API for this Metarelease Fall25 I would like to align the WG strategy:

I think we can align in using: CUSTOMER_INSIGHTS.INVALID_IDENTIFIERS

and for Spring 26 change this exception into a transversal "INVALID_IDENTIFIERS" or similar one as per agreement in Commonalities

Please @KevScarr if you can approve again after PR #52 alignment

Please @rartych, review on your back for your ok as well

Thanks @KevScarr, @rartych for the review.
I merge it and generate PR for Public Release